After nearly two years stuck with rEFIt 0.7 in Debian, I’ve uploaded rEFIt 0.11 to unstable today. There’s been a bit of work done on the package, on rEFIt itself and on the tools that come with rEFIt. I’ve also added some (useful, I hope) documentation. This version of rEFIt supports all Intel Macs to date. rEFIt in Debian comes with gptsync, both as a Unix command-line tool and as an EFI application. It’s the only tool shipped in the package. The other tools available in the rEFIt binary distribution by upstream (the EFI Shell and utilities) come from the TianoCore project and aren’t available in Debian. See the README.Debian in rEFIt if you want the full story. Also rEFIt in Debian lacks the machine shutdown feature for now; this feature is part of the EFI 1.10 spec which isn’t supported by gnu-efi yet, though I have also worked on updating gnu-efi for EFI 1.10 and sent this upstream. Filesystem drivers are also affected by this and, as such, are unavailable too. If you’re interested in the gory details, see the changelog and patches.

I’ve just released pommed v1.18, which is mainly a maintenance release. I’ve added some more USB IDs for Apple external keyboards and relaxed the event devices identification for internal keyboards. pommed will now happily start on a machine fitted with a keyboard+trackpad assembly that normally isn’t found on this model. This can happen when the topcase of the machine is replaced with the wrong part. I expect this situation will happen more and more often as people buy parts from EBay or similar to repair their laptops.

Because a lolcat is worth a thousand jokes, here are 3 of them. Thanks to rominet for coming up with those :-)

Dear Daniel, It looks like you are referring to my post, though you got my name wrong so that wasn’t immediately obvious. Of course this is far worse than the 2003 compromise in terms of the direct, known and quantifiable impact it has on our users. I don’t think I stated otherwise, so I hardly see why your post starts with “I disagree”.

NOT. Also see #363516. Genius. Now regenerating every single SSH key, SSL certificate and whatever else I can identify that’s been produced by one of the Valgrind-clean openssl. Also expiring and changing every single password I’ve ever typed in a vulnerable SSH session (be it at login or in the session). Updating the packages on the machines was fun already. Worst Debian day ever since the 2003 compromise. And that was a BAD one. I guess we need a new openssl maintainer, we obviously cannot trust the current one(s).

The SANE project is working on improving SANE, extending the API and ABI in a backward-compatible manner and bumping the version from 1.0.x to 1.1.x to celebrate that. The timetable has been posted, and calls for a release of SANE 1.1.0 on July, 30th. This will be too late for the Lenny freeze by a few weeks, which means Lenny is set to be released with SANE 1.0.19. SANE 1.0.19 is a good, solid release, which is good news. I’m not sure 1.1.0 will be as solid as 1.0.19 is, so I won’t try to rush 1.1.0 into Lenny at the last minute. Until the Lenny freeze, I’m going to augment the current SANE 1.0.19 with code from the SANE CVS, concentrating mostly on bugfixes and self-contained new hardware support and features. Hence, if there is something in the SANE CVS that you would like to see in Lenny: test it, then tell me about it. You have until the end of June to do so. Currently on my TODO list:

• pixma backend update

Currently in experimental, sane-backends 1.0.19-7:

• saned & net backend with mDNS/DNS-SD support
• debconf support for enabling saned

Comments and feedback welcome.

Trying to upgrade a craptastic server that’s proving problematic under 2.6.18 to the Etch 1/2 kernel, not only is the machine extremely sloooooow to boot, but it turns out that it’s partly due to bnx2 now requesting a firmware file, whereas the firmware is built-in in the 2.6.18 Etch kernel. Of course, the machine has no working network access due to this, and, to make things even worse, the firmware file is nowhere to be found. No firmware-nonfree in etch-proposed-updates and it’s not in the firmware-nonfree package in unstable. You’d better hide your kittens, for Etch 1/2 makes me want to kill a large number of kittens.

Put down the crack pipe. Really. Wow.

Dear Jaldhar, I wrote the post you’re referring to knowing that only one person had been stupid enough to title his post “Is Debian dying?”, so before you go on writing I’m insulting a group of people (at least I’m reading your post this way), please do your research. Lucas’ post is about the worst PR we can imagine. There’s nothing more stupid to do than what he did. That’s the PR equivalent of committing suicide, mostly. It’s seriously hindering the work some of us are doing, publicizing Debian, going to trade shows, etc. It’s not only stupid, it’s hurting people who do this work. What’s worse, the post comes with comments from random nobodies, who have nothing to do with Debian, don’t have the first clue about how the Project works internally, yet they can tell that Debian is dying and grinding to a halt. Not to mention it’s been publicized yet again by some “journalist”. I’ve known Lucas for a long time now. I know where I stand. And I maintain my previous post in full, like it or not. Kthxbye.

NagVis is a visualization add-on for Nagios, offering a somewhat better summary view compared to Nagios. As we are faced with abysmal performance on a “large” setup here, I conducted a quick analysis. Given what I found pretty early on during this analysis, I’ve given up trying to salvage NagVis. We’re looking at alternatives and considering writing our own tool to cover our needs.

New developer accounts have been created moments ago, “finally”. Congratulations to all new DDs, with a special note for Aur lien G R ME (ag) and Cyril BRULEBOIS (KiBi). All of this made possible by Sam, our best DPL to date. Also, don’t listen to the fucktards going around telling “OMG DEBIAN IS DYING!!11!1!”. They’re just that, fucktards.

I’ve just released pommed v1.17, which is a pure maintenance release to accomodate changes in Linux 2.6.25. The path for the led interface exposed by applesmc for the keyboard backlight has changed, so if you lost the keyboard backlight when switching to 2.6.25 or a pre-release, now you know why ;) No new features this time around :-)

There have been a number of discussions on sane-devel in the past months revolving around the SANE2 standard (still in development) and/or extensions to the current SANE1 standard. SANE2 is an effort that has been “ongoing” (on and off, mostly off, unfortunately) for a number of years already. This led to a number of questions being raised, most notably this one: do we need SANE2, or can we get away only with extensions to SANE1? Or should we just redesign the whole stack from the ground up?
This matter is undecided as of yet, but extensions to SANE1 are planned, being discussed or in the making for some of them. During the discussions, a fork of SANE has been announced, dubbed “SANE Evolution”. No idea where that is going, but it’ll probably end up being merged back into SANE in the end. So, in a nutshell, things are moving again (albeit slowly), which is good news considering the project was mostly asleep in recent times. To celebrate that (and because I now have total control over my free time again), I’ve been working on the network side of SANE again. In 2 weeks (3 week-ends, roughly):

• saned has been turned into a regular, full-fledged daemon
• mDNS/DNS-SD service announcement & discovery has been added to saned and the net backend (using Avahi)
• I have 20% of a WireShark dissector for the SANE protocol written, and already spotted (and plugged) an information leak bug in the net backend thanks to it

Turning saned into a regular daemon made it possible to clean up a good chunk of the code duplication that was introduced by my previous AF-indep/IPv6 work; the startup code is readable again. The Avahi support is (I hope) a very nice thing as, when enabled, configuration of the net backend on the client side is no longer needed. This is an experimental feature still and as such it’s disabled by default at build time. I have a couple of ideas to improve that feature, but this means saned will have to evolve even more so it’ll take some time. The WireShark dissector is a tool for working on enhancing the network protocol. It proved useful already with the information leak I spotted with it (though it’s minor). It’ll be a long work to extend the network protocol and implement that into saned and the net backend in a backward-compatible manner.

In June last year, I bought a TomTom GPS device. Their use of Linux on the device was a clear plus in their favour, but it was only that, given that overall they’re the best devices available. Unfortunately, the TomTom HOME software that is needed to manage the device is not as good as the device itself. An account on their website is needed for updates and the online shop, and as I usually do, I used an email address in the form jb+something@jblache.org. That’s a trick most of us use to trace back the origin of spam, usually revealing that some company sold its customer database. I’ve been doing that for years. I was quite happy that the website did not reject the address as being invalid; that’s something that happens everytime the random web developer maintaining the site decides to start “validating” email addresses, for some value of email addresses. For the following 8 months I’ve been using this address as the account login (don’t really have the choice, anyway) with the TomTom HOME software. Last month, the v2 of the said software was finally made available for Mac OS X. Where the v1 used to accept my email address, the v2 would now reject it. You guessed it, Joe Random developer decided to start validating email addresses in TomTom HOME. I reported the regression (and here, something must be said about their infamous support website), with pointers to the relevant RFCs. In the following email ping-pong, they managed to:

• Pretend the password was the problem. I have to say here that the software displays a big red “invalid email address” next to the email address field as soon as I enter the + character. No mistake possible here.
• Send me my login and password, in clear text, when I never asked for that. That also means they’re storing passwords in clear text. IT’S 2008 FOR FUCK’S SAKE! STOP STORING CLEAR TEXT PASSWORDS, DAMMIT.
• Pretend their email platform is the most secure in the world. Ever heard of SSL? TLS? Clearly not.
• Pretend it’s not a regression in the v2 of TomTom HOME. We’re not speaking the same language, it seems.
• Pretend the email address is invalid. No surprise there, but it’s clear they did not bother reading the fucking RFC.

Last but not least, their last reply was: “we found that the standard does not apply to us. Please change your email address for a valid one.” Now, I’m left wondering: does the GPS standard apply to TomTom devices? I truly hope so.

I’ve finally got enough information to complete the MacBookAir1,1 support, it’s been tested and it works. I’ve also got the information I needed for the new MacBook Pro and MacBook released in February 2008, but there I’ll need some feedback. I have some doubts on which machine uses which keyboard+trackpad assembly.

• The MacBook Air uses an entirely new device, the so-called “MultiTouch” trackpad, dubbed “WellSpring”
• The MacBook Pro has got a “MultiTouch” trackpad in its latest revision, so it’s using a WellSpring device too, and I think it’s using the WellSpring II device
• The MacBook hasn’t got the “MultiTouch” trackpad, I think it still uses a Geyser IV-HF device

I’ll need to confirm those two last points, so if you are running pommed on either one of these machines, your feedback is welcome. On a slightly related note, I have some sound troubles on my MacBookPro2,2 with 2.6.24.3 which I didn’t have with 2.6.24.2. I cannot play WAV files anymore, be it with pommed, with aplay or with any other software. In the best case, the sound is distorted and too fast, in the worst case I can’t hear anything at all. And they call it the stable tree, hmgrmpf.

I’ve released pommed v1.15 this week-end with support for the new power_supply class which is used to report ACPI power information starting with kernel 2.6.24. This release also contains pretty much everything needed for the MacBook Air1,1, except the keyboard/trackpad USB IDs which I couldn’t grab yet. So expect v1.16 for the MacBook Air as soon as I’ll have those IDs.

http://lists.debian.org/debian-devel-announce/2008/01/msg00006.html I fear it’s a little bit too late to introduce a release goal such as this one, which will probably have quite a few (tricky) side effects. I think it’s time to stop piling release goals, or we’re never going to release.

Jan 26 11:26:35 arrakis sshd[2515]: pam_unix(ssh:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=my-debian.org
Jan 26 11:26:38 arrakis sshd[2515]: Failed password for invalid user myra from 88.151.100.103 port 53744 ssh2

Note the rhost in the first line: my-debian.org. And, indeed:

% host my-debian.org
my-debian.org has address 88.151.100.103

Whois tells me:

Registrant ID:DI_6983786
Registrant Name:Czibulya Gergely

LART, anyone ?

Spamming every @*.debian.org email address you can find to advertise your new website related to free software is not a good idea. At all. If you know this person IRL, please make heavy use of the cluebat on him. kthxbye.

A bugfix release for pommed, fixing a crash when the default beep file is not available. One part of the audio code we’ve reused had a broken error handling, and you know how that kind of things tend to end (badly). Also, the default beep sound was pretty horrible according to the feedback I’ve got so far, so the default beep sound has changed and another sound is shipped if you don’t like the default (the clicking sound that was in gpomme).